Method and server device for providing internet of things platform service

ABSTRACT

A method and a server device for providing an IoT platform service are provided. According to at least one aspect of the present disclosure, a method of providing an IoT platform service, which is performed by an IoT platform server apparatus, generates a shadow device corresponding to an IoT device, manages state information of the IoT device through the corresponding shadow device, and registers and administers a specification (i.e., a device descriptor) regarding common features of a plurality of devices.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/652,640 filed on Mar. 31, 2020, which is a U.S. National StageApplication of International Application No. PCT/KR2018/010696 filed onSep. 12, 2018, which claims priority from Korean Patent Application No.10-2017-0135919 filed on Oct. 19, 2017, and Korean Patent ApplicationNo. 10-2017-0141491 filed on Oct. 27, 2017, the disclosures of which areincorporated by reference herein in their entirety.

TECHNICAL FIELD

The present disclosure in some embodiments relates to a method and aserver device for providing an Internet of Things platform service.

BACKGROUND

The statements in this section merely provide background informationrelated to the present disclosure and do not necessarily constituteprior art.

The IoT platform service is a service that provides common functionsnecessary for the development or operation of Internet of Things (IoT)services. By utilizing the functions provided by the platform, IoTservice developers can develop and operate their services more quicklyand easily. In addition, IoT service users can manage the connection ofthings and monitor the status on the platform, enabling stable serviceutilization. The IoT platform focuses on managing connections betweenIoT devices and application servers and stably transmitting data betweenIoT devices and application servers to achieve stable IoT serviceoperations.

In the conventionally developed IoT platform, since only the currentstate of the IoT device is provided in synchronization and only simplerule processing using the current state is performed, there is a limitin developing a service using the IoT device on the platform. In orderto provide a complex and practical service involving data of multipledevices or past data, the application server needs to store and processdata, which requires an additional development process.

DISCLOSURE Technical Problem

The present disclosure in some embodiments seeks to provide an IoTplatform service method and apparatus capable of providing various dataprocessing functions by managing data of IoT devices in a platform.

Another embodiment of the present disclosure is to provide an IoTplatform service method and apparatus that can provide variousconvenience functions and data processing functions by defining andmanaging data of IoT devices by using a device descriptor.

SUMMARY

At least one aspect of the present disclosure provides a method ofproviding an Internet of Things (IoT) platform service, the methodincluding generating a shadow device corresponding to each of one ormore IoT devices, receiving state information of the IoT device andstoring the state information in the shadow device every time the stateinformation is updated, and performing a predetermined operation basedon stored state information in the shadow device.

Another aspect of the present disclosure provides an IoT platformservice server apparatus including a communication unit, a shadow devicemanager, and a rule engine. The communication unit is configured tocommunicate with one or more IoT devices. The shadow device manager isconfigured to perform a control for generating a shadow devicecorresponding to each IoT device, and for receiving state information ofthe IoT device and storing the state information in the shadow deviceevery time the state information is updated. The rule engine isconfigured to determine whether a predetermined rule condition issatisfied by using stored state information in the shadow device.

Yet another aspect of the present disclosure provides a method ofproviding an Internet of Things (IoT) platform service, the methodincluding registering a specification (hereinafter, referred to as a‘device descriptor’) for common features of a plurality of devices,receiving a connection request from one or more IoT devices, generatinga shadow device corresponding to each IoT device, receiving data fromthe IoT device, and updating a state of the shadow device based on datareceived from the IoT device.

Yet another aspect of the present disclosure provides an IoT platformservice server apparatus including a registration unit, a communicationunit, and a virtualization unit. The registration unit is configured toregister a specification (hereinafter, referred to as a ‘devicedescriptor’) for common features of a plurality of devices. Thecommunication unit is configured to communicate with one or more IoTdevices. The virtualization unit is configured to generate, on a serverof the IoT platform service server apparatus, a shadow devicecorresponding to each IoT device, and to update a state of the shadowdevice based on data received from the IoT device.

Advantageous Effects

As described above, according to some embodiments of the presentdisclosure, data of IoT devices may be managed and processed within theIoT platform, thereby providing various IoT services.

In addition, according to some embodiments of the present disclosure,various rules can be defined and provided to be executable within theIoT platform, whereby providing real-time data processing easily andquickly without involving an application server.

In addition, according to embodiments of the present disclosure, even ifan IoT device is temporarily disconnected from the Internet, one canstill retrieve the state information of the IoT device, store a commandto be transmitted to the IoT device, and deliver the same command to theIoT device once the connection is resumed, whereby providing stableoperation of the IoT service.

In addition, according to embodiments of the present disclosure, thedevice descriptor of the IoT platform may be used to determine thesemantics of data received from the IoT device, thereby facilitatingconnection to various rules.

In addition, according to embodiments of the present disclosure, thedevice descriptor of the IoT platform may be used to determine thesemantics of the data received from the IoT device, thereby facilitatinglinkage with an external analysis service.

In addition, according to embodiments of the present disclosure, thedevice descriptor of the IoT platform may be used to easily determinewhether there is a miss of data received from the IoT device.

In addition, according to embodiments of the present disclosure, thedevice descriptor of the IoT platform may be used to easily determinewhether there is an error in the data received from the IoT device.

In addition, according to embodiments of the present disclosure, thedevice descriptor of the IoT platform may be used to collective managethe data received from IoT devices, thereby reducing development timewhen developing the IoT service for devices having a common property orfeature.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram of a structure of an IoT platformsystem according to some embodiments of the present disclosure.

FIG. 2 is a block diagram of a configuration of an IoT device accordingto at least one aspect of the present disclosure.

FIG. 3 is a block diagram of a configuration of an IoT platform serveraccording to at least one aspect of the present disclosure.

FIG. 4 is a flowchart illustrating a rule engine based IoT devicecontrol method in an IoT platform system according to at least oneaspect of the present disclosure.

FIG. 5 is a flowchart illustrating a method of controlling an IoT deviceby an application server in an IoT platform system according to at leastone aspect of the present disclosure.

FIG. 6 is a block diagram of an IoT platform server according to anotheraspect of the present disclosure.

FIG. 7 is a block diagram showing in detail the structure of an IoTsystem according to another aspect of the present disclosure.

FIG. 8 is a flowchart illustrating a method of providing an IoT platformservice according to yet another aspect of the present disclosure.

DETAILED DESCRIPTION

Hereinafter, some embodiments of the present disclosure will bedescribed in detail with reference to the accompanying drawings. In thefollowing description, like reference numerals designate like elements,although the elements are shown in different drawings. Further, in thefollowing description of some embodiments, a detailed description ofknown functions and configurations incorporated therein will be omittedfor the purpose of clarity and for brevity.

Additionally, various terms such as first, second, A, B, (a), (b), etc.,are used solely for the purpose of differentiating one component fromthe other, not to imply or suggest the substances, the order or sequenceof the components. Throughout this specification, when a part “includes”or “comprises” a component, the part is meant to further include othercomponents, not to exclude thereof unless specifically stated to thecontrary. The terms such as “unit,” “module,” and the like refer to oneor more units for processing at least one function or operation, whichmay be implemented by hardware, software, or a combination thereof.

The detailed description, which will be given below with reference tothe accompanying drawings, is intended to explain exemplary embodimentsof the present disclosure and is not intended to represent the onlyembodiments in which the present disclosure may be practiced.

FIG. 1 is a schematic block diagram of a structure of an IoT platformsystem according to some embodiments of the present disclosure.

As shown in FIG. 1, an IoT platform system 100 according to someembodiments includes at least one IoT device 110, an IoT platform server130, and an application server 150 that interwork with each otherthrough a communication network.

In this case, the connection of the IoT device 110 to a communicationnetwork includes a case of the IoT device 110 connecting to a wirelessaccess device (not shown) using short-range wireless communicationtechnology and being connected to a communication network. Theshort-range wireless communication technology may include acommunication technology such as Wi-Fi, Zigbee, Bluetooth, and NFC (NearField Communication) schemes. The wireless access device is adapted tosearch for the IoT devices 110 present in the communication coverageaccording to the corresponding short-range wireless communicationstandard, establish a connection with the discovered IoT devices 110,and then perform a connection setup and data transmission and receptionwith the IoT platform server 130.

In some embodiments, the communication network through which therespective components of the IoT platform system 100 interwork with eachother collectively refers to various types of established communicationnetworks, for example, closed networks including a local area network(LAN), a wide area network (WAN), or the like, open networks such as theInternet, as well as mobile communication networks including CodeDivision Multiple Access (CDMA), Wideband Code Division Multiple Access(WCDMA), Global System for Mobile Communications (GSM), Long TermEvolution (LTE), etc., and Wi-Fi networks not to mention other currentlyavailable or coming next-generation network and computing networkimplementations.

The IoT device 110 is a device having a sensor function and acommunication function and connected to a communication network totransmit and receive data. The IoT device 110 may be implemented asvarious embedded systems such as home appliances, mobile equipment, andwearable computers. The IoT device 110 connects to the IoT platformserver 130 through a communication network and transmits data such asstatus information or sensing information to the IoT platform server 130to perform a predetermined function at the control command from the IoTplatform server 130. In this case, the IoT device 110 may access awireless access device (not shown) that performs short-range wirelesscommunication to establish a connection and then access the IoT platformserver 130 through the wireless access device.

The IoT platform server 130 is a platform apparatus for providing anIoT-based service. The IoT platform server 130 provides functions toregister and authenticate the IoT device 110, collect and manage data ofthe IoT device 110, and control the IoT device 110 among otherfunctions. Developers of IoT services may utilize such functionsprovided by the IoT platform server 130 to develop various IoT-basedservices. In addition, by way of the IoT platform server 130, the usermay manage and monitor the connection and operation control of the IoTdevice 110 for the Internet of Things services.

The application server 150 is connected to the IoT platform server 130and serves to manage and control a unique service for each applicationprogram by using various types of information of the IoT device 110transmitted via the IoT platform server 130. There may be multiples ofthe application server 150, and they may provide, through respectiveservers, various application services for a smart home, a smart car, andother smart services. In particular, the application server 150 of thepresent disclosure collects various pieces of information of the IoTdevice 110 through the IoT platform server 130 and transmitscorresponding control information to the IoT device 110 through the IoTplatform server 130.

FIG. 2 is a block diagram of a configuration of an IoT device accordingto at least one aspect of the present disclosure.

As shown in FIG. 2, the IoT device 110 may include a storage unit 210, acontrol unit 230, and a wireless communication unit 250. The componentsshown in FIG. 2 may be implemented respectively as hardware chips, orthey may be implemented in software so that a microprocessor executes asoftware function corresponding to each component.

The storage unit 210 stores programs and data necessary for theoperation of the IoT device 110. The storage unit 210 may store datasuch as sensing information or state information collected by the IoTdevice 110 at predetermined intervals. In addition, the storage unit 210may store a program for performing processing in the IoT device 110,such as the collection and transmission of sensing information or stateinformation.

The control unit 230 is a means for controlling the IoT device 110. Thecontrol unit 230 includes a processor for executing a computer programdesigned to implement the features according to some embodiments of thepresent disclosure and thereby processes the collection and transmissionof the sensing information and the state information throughinterworking with the IoT platform server 130 and the execution of theremote control command.

The wireless communication unit 250 is configured to transmit andreceive data through a communication network, and it may transmit andreceive data through various communication schemes as well as a wiredmethod and a wireless method. The wireless communication unit 250 mayestablish a communication session with the IoT platform server 130through a communication network, whereby transmitting and receiving datanecessary for the IoT service.

In at least one embodiment of the present disclosure, in order for theIoT device 110 to be connected to a communication network, the wirelesscommunication unit 250 may be connected to a wireless access device in ashort-range wireless communication method to transmit and receive data.For example, once the wireless communication unit 250 is connected to awireless access device after going through discovery, authentication,and combining process according to short-range wireless communicationstandards such as Wi-Fi, Zigbee, and Bluetooth, it may transmit andreceive data to and from the wireless access device.

FIG. 3 is a block diagram of a configuration of an IoT platform serveraccording to at least one aspect of the present disclosure.

As shown in FIG. 3, the IoT platform server 130 may include acommunication unit 310, a control unit 320, a shadow device manager 330,shadow devices 340, a rule engine 350, and a user interface 360. Thecomponents as shown in FIG. 3 may be implemented respectively ashardware chips, or they may be implemented in software so that amicroprocessor executes a software function corresponding to eachcomponent.

The communication unit 310 is configured to transmit and receive datathrough a communication network and may transmit and receive datathrough various communication methods as well as wired and wirelessmethods. The communication unit 310 may establish a communicationsession with the IoT device 110 or the application server 150, whichaccesses through a communication network, whereby transmitting/receivingdata to/from the IoT device 110 or the user application server 150.

The control unit 320 is a configuration for controlling overall IoTplatform services, which may register a plurality of IoT devices 110according to a service algorithm, and may manage and process datatransmitted from the registered IoT devices 110. In addition, at arequest of the application server 150, the control unit 320 searches andprovides data, or it controls the shadow device manager 330 totransmit/receive data so that the received command can be transmitted tothe relevant IoT device 110. For the purpose of security, the controlunit 320 checks the authority of the IoT device 110 and the applicationserver 150 for the authentication and request, and according to theconfirmed authority, the control unit 320 processes requests or datasent from the IoT device 110 and the application server 150.

The shadow device manager 330 may manage matching information betweenthe IoT device 110 and one or more shadow devices 340, and it may storeand manage data for the shadow devices 340 respectively corresponding tothe IoT devices 110. At a connection request of the IoT device 110 madeto the IoT platform server 130, the shadow device manager 330 generatesa corresponding shadow device 340. The shadow device manager 330 storesthe data transmitted from the IoT device 110 in the corresponding shadowdevice 340, and retrieves and provides the data according to a requestof the application server 150. In addition, when there is a controlcommand for the IoT device 110 through the application server 150, theshadow device manager 330 stores the control command information in theshadow device 340 and renders the control command information stored inthe shadow device 340 to be transmitted to the IoT device 110.

In preparation for storing data in the shadow device 340, the shadowdevice manager 330 may first process data previously stored in theshadow device 340 and data to be newly stored (history data) thereinaccording to a rule defined in the rule engine 350. The shadow devicemanager 330 may reduce or abbreviate and store data through a dataaggregation process for history data according to a rule designated by auser. For example, the shadow device manager 330 may aggregate the stateinformation for a predetermined time to store, in the shadow device 340,statistical values such as a maximum value, a minimum value, an averagevalue, a count value, a variance, an average value for each time zone,and a representative value for a data group. Taking account of a largeamount of storage space to store the history data in its unabridged rawdata form in the shadow device 340 and a high processing cost for datatransfer, the shadow device manager 330 may process the data through therule engine 350 and then store the processed data in the shadow device340.

The shadow device 340 is a logical entity on a server, which is mappedone-to-one with a physical device or a virtual device and exists in aone-to-one correspondence with the registered IoT device 110. In thiscase, the IoT device 110 may include not only a physical device but alsoa virtual device, and thus, the shadow device 340 may exist alonewithout the physical device on the platform. The shadow device 340 isalways present in synchronization with the current state of the IoTdevice 110, and it may store history-based information as well ascurrent state information of the IoT device 110. The shadow device 340may receive and store state information of the IoT device 110.Furthermore, each time the state information is updated, the shadowdevice 340 may accumulate and store updated state information whilemaintaining previously stored information.

In addition, the shadow device 340 stores information on a controlcommand transmitted to the IoT device 110. The IoT platform server 130may transmit a control command to the IoT device 110 at a request fromthe application server 150 or when a rule condition defined in the ruleengine 350 is satisfied. In this case, the shadow device 340 storescontrol command information transmitted to the IoT device 110 and aresult of the control command performed by the IoT device 110. Theshadow device 340 may likewise store the control command information andthe control result when there is a control request from the applicationserver 150 over the IoT device 110.

In other words, the shadow device 340 is a logical IoT devicecorresponding to the IoT device 110 implemented in the IoT platformserver 130. The shadow device 340 is configured to store the currentstate information and the past state information of the IoT device 110and all control commands received or performed by the IoT device 110. Adeveloper developing an IoT service through an IoT platform or a userusing the IoT service is supposed to monitor and control the IoT servicethrough the IoT device 110 or the application server 150. At this time,the IoT platform server 130 does not merely work to transfer databetween the IoT device 110 and the application server 150, but alsostores and manages the state information and the control information ofthe real IoT device 110 in its matching shadow device 340.

In addition, even when the IoT device 110 is temporarily disconnectedfrom the Internet, the shadow device 340 stores the state information ofthe IoT device 110, and it is capable of providing data when requestedby the application server 150 and keeping the data when there is acontrol command of the IoT device 110 until the latter is reconnected tothe Internet when the shadow device 340 can provide the data to the IoTdevice 110. This enables reliable operation of the IoT service even withunstable Internet connections.

The rule engine 350 provides a function of automatically processing dataaccording to a predefined rule. The rule engine 350 provides a functionof setting various rules based on data stored in the shadow device 340and may perform various operations by itself without special input,according to a rule set by a user.

For example, when data below a specific value repeats itself for acertain period of time, the rule engine 350 may have an operationautomatically performed as is set in the rule. Such operation mayinclude providing an alarm to the user or giving control commands torestart the device.

In some embodiments, the rule engine 350 may use history data as well asthe current state data of the IoT device 110, whereby allowing to setrules by using various data and enabling the IoT platform server 130 toautonomously provide extensive data processing in real-time.

For example, the rule engine 350 may use history data of the IoT device110 for setting a rule to give an alarm in response to incoming datathat deviates from the average value for the last hour, or for setting arule to issue a specific control command for incoming data that fallsoutside 10% of the maximum value during the past day in relation to theIoT device 110 in a group of organized IoT devices 110.

The conventional IoT platform system has the IoT platform server obtainand store just the current state information of the IoT device, allowingthe built-in rule engine to at best perform simple data processing usingthe current state information. In order to provide complex and diverseservices, it has been common to implement dedicated functions of storingand processing data to the respective complex and diverse services in anapplication server. With the IoT platform system according to someembodiments of the present disclosure, the history data of the IoTdevice can be used for setting rules in the rule engine, wherebyallowing the IoT platform server to autonomously perform various typesof data processing saving the need for implementing those dedicatedfunctions in an application server.

The user interface unit 360 provides a user or a developer with aninterface for inputting or selecting basic information and protocolinformation of an IoT service. The user interface 360 provides a userinterface (UI) screen through which a user or developer can define acommunication server or protocol. Such a user interface screen may beused by a general non-programmer user through a checkbox and a checklistto drive a communication server module and generate an interface betweenan IoT terminal and a server. At this time, the UI screen is configuredto allow the user to make all settings for the server and protocol witha simple click.

FIG. 4 is a flowchart illustrating a rule engine based IoT devicecontrol method in an IoT platform system according to at least oneaspect of the present disclosure.

As shown in FIG. 4, when there is a connection request of the IoT device(S401), the IoT platform server generates a corresponding shadow device(S402). In this case, the IoT device may include a virtual device aswell as a physical device. A shadow device is a logical entity existingon a server by mapping one-to-one with a physical device or a virtualdevice, and it exists in a one-to-one correspondence with an IoT device.In some embodiments of the present disclosure, the shadow devicereceives and stores state information of the IoT device, and preferablyaccumulates and stores the updated state information while maintainingthe pre-stored information whenever the state information is updated.The process of generating the shadow device in Step S402 is performedonly once at the first access request of the IoT device.

The developer or user of the IoT service sets rules conditions foroperating the service through the application server (S403). The ruleengine is a configuration that provides a function for automaticallyprocessing data under these predefined rule conditions. The rule engineof the IoT platform server may determine whether the rule condition issatisfied by using state information stored in the shadow device.

For example, the rule engine may use the history data of the IoT devicesfor setting a rule to alarm in response to incoming data that is out ofthe average value for the last hour, or for setting a rule to issue aspecific control command for incoming data that falls outside 10% of themaximum value during the past day in relation to the IoT device in agroup of organized IoT devices.

Since the rule engine can use the history data of the IoT device, rulescan be set by using various data. Through this rule engine, a developercan provide various services without processing data through anapplication server.

When data is transmitted from the IoT device (S404) and received by theIoT platform server, the latter stores the received data on the shadowdevice (S405). In Step S405, the pre-stored data and new data to storemay be processed and stored according to a rule defined in the ruleengine. The data may be reduced or abbreviated and stored through dataaggregation processing of history data according to a user-specifiedrule. For example, the state information for a predetermined time may beaggregated to store, in the shadow device, statistical values such as amaximum value, a minimum value, an average value, a count value, avariance, an average value for each time zone, and a representativevalue for a data group. Taking account of a large amount of storagespace to store the history data in its unabridged raw data form in theshadow device and a high processing cost for data transfer, the shadowdevice manager may process the data through the rule engine and storethe processed data in the shadow device.

The rule engine in the IoT platform server determines whether datastored in the shadow device meets predetermined rule conditions (S406),and if yes, it performs a predetermined operation such as issuing acontrol command to the IoT device (S407). The IoT device follows thecontrol command, and when it transmits the control results to the IoTplatform server (S408), the IoT platform server stores the controlresults in the shadow device (S409).

The shadow device is configured to store current state information, paststate information, and control commands of the IoT device, and StepsS405 and S409 are performed repeatedly whenever there is datatransmission from the IoT device or control command to the IoT device.Through these steps, the IoT device and its shadow device may alwaysexist in synchronization, and the shadow device may store history dataand information on control commands generated so far.

When there is a request for information on IoT devices from theapplication server (S410), the IoT platform server transmits the IoTdevice-related information stored in the shadow device to theapplication server (S411). The IoT platform server transmits theinformation stored in the shadow device without having to receive orrequest the current state information of the IoT device.

In the existing IoT platform system, the embedded rule engine could onlyperform simple data processing using the current state information, andit was common to implement this in an application server in order toprovide complex and various services. With the IoT platform systemaccording to the present embodiments, the shadow device on the platformstores the history data of the IoT device until it can be used, allowingthe history data to be available for rule setting in the rule engine andthereby enabling the IoT platform server to autonomously process varioustypes of data without going through an application server.

FIG. 5 is a flowchart illustrating a method of controlling an IoT deviceby an application server in an IoT platform system according to at leastone aspect of the present disclosure.

In the following, a repetitive description of FIG. 4 will be omitted toavoid redundancy.

As shown in FIG. 5, when there is a connection request of the IoT device(S501), the IoT service server generates a corresponding shadow device(S502). The generation of the shadow device in Step S502 is performedonly once at the first request for the connection of the IoT device.When data is transmitted from the IoT device (S503) and received by theIoT platform server, the platform server stores its received data in theshadow device (S504). The shadow device may exist in synchronizationwith the IoT device at all times through Step S503 and Step S504 and maystore history data.

The application server requests the IoT platform server based on thedata received in the IoT platform server to transmit a control commandto the IoT device (S507). The IoT platform server stores the controlcommand in the shadow device (S508) and transmits the control command tothe IoT device (S509). When the IoT device performs a command followingthe control command and transmits the control result to the IoT platformserver (S510), the IoT platform server stores the control result in theshadow device (S511). When the application server inquires or requeststo transmit the control result (S512), it receives the transmitted dataout of the shadow device in the same manner as the data inquiry processof Step S505 (S513).

Even if the IoT device is temporarily disconnected from the Internet,the shadow device storing the state information of the IoT device makesthat information available whenever there is a data request from anapplication server. The shadow device also holds a control command whenissued on the IoT device until it can deliver the same to the IoT devicewhen reconnected to the Internet, thus enabling stable operation of theIoT service regardless of whether the IoT device is connected to theInternet.

FIG. 6 is a block diagram of the configuration of an IoT platform serveraccording to another aspect of the present disclosure.

As shown in FIG. 6, the IoT platform server 130 according to anotheraspect of the present disclosure includes a communication unit 610, aregistration unit 630, and a virtualization unit 650.

The communication unit 610 may transmit/receive data in a wired,wireless, or other various communication methods through a communicationnetwork.

The communication unit 610 may be configured to establish acommunication session with the IoT device 110 or the application server150 accessing through a communication network, and to transmit andreceive data with the IoT device 110 or the application server 150through the communication session.

The registration unit 630 may perform registration and authentication ofIoT devices 110, and register and manage specifications of commonproperties or features of common feature IoT devices 110.

In this case, a specification for the common features of the commonfeature IoT devices 110 will be referred to as a device descriptor 631.

The virtualization unit 650 may generate a shadow device correspondingto each IoT device 110 on the IoT platform server 130, and update thestatus of the shadow device based on the data received from the IoTdevice 110.

The virtualization unit 650 may manage matching information between theIoT devices 110 and their shadow devices and store and manage data foreach of the plurality of shadow devices corresponding to its IoT device110. At an access request by the IoT device 110 with respect to the IoTplatform server 130, the virtualization unit 650 generates the shadowdevice corresponding to that IoT device 110. The virtualization unit 650stores the data transmitted from the IoT device 110 in the correspondingshadow device, and retrieves and provides the data according to arequest of the application server 150. In addition, upon receiving acontrol command for the IoT device 110 through the application server150, the virtualization unit 650 stores information on the controlcommand in the shadow device and renders the control command informationstored in the shadow device to be transmitted to the IoT device 110.

The IoT platform server 130 according to another aspect of the presentembodiment may further include a check unit 670.

The check unit 670 may check the validity of the data received from theIoT device 110 based on the device descriptor 631.

Device Descriptor

(1) Configuration of Device Descriptor

The device descriptor 631 may include one or more of information aboutsensors common to the common feature IoT devices 110, information oncontrollable modules common to the common feature IoT devices 110, andinformation on the semantics, format, periodicity, transmission cycle,numerical range, and variable range of common data transmitted by thecommon feature IoT devices 110 to the IoT platform server 130.

The device descriptor 631 is capable of designating not only thesemantics of data transmitted by the device but also the format so thatthe user can transmit data in the desired format. In particular, takingaccount of the IoT service property that values size reduction of thetransmission data, the device descriptor 631 can transmit data in notonly json format but also in reduced size of csv or offset based format.In spite of the reduced size, the device descriptor holding the contentof the data enables the relevant IoT platform to provide a service basedon the semantics of data.

The IoT device 110 may include one or more sensors and one or morecontrollable modules. The sensor may be a temperature sensor, a humiditysensor, a global positioning system (GPS), or the like, and thecontrollable module may be a motor, an actuator, a cooling fan, aheating wire, or the like.

Since the common feature IoT devices 110 are similar to each other bytheir sensor types and the controllable module types, the platform stagewith features defined common to the common feature IoT devices 110according to the present disclosure allows IoT service developers toeasily develop a service provided to the common feature IoT devices 110.

The device descriptor 631 is a logical framework representing the commonfeature IoT devices 110, and not only has a specification of the IoTdevices 110 but also all the information on, objects such as sensors andactuators linked to the IoT devices 110, the semantics of transmitteddata, its format, and transmission cycle, and is a logicalrepresentative of the common feature IoT devices 110.

The IoT service developer may write information about a device to beused in the IoT service conforming to the format of the devicedescriptor 631 provided by the IoT platform. The device descriptor 631may include Name, Device information, Attributes, Telemetries, and thelike.

Name means the name of the device descriptor 631.

The device information is about the IoT device 110 itself and mayinclude information on a manufacturer, a memory, a model, a version, agateway, a connected sensor, and a controllable module.

Attributes mean the latest state information without periodicity amonginformation transmitted by the IoT device 110. Attributes can be definedby IoT service developers themselves according to their service featuresor characteristics and can define names, types, semantics (definition ofwhat this information actually means), controllability, datatransmission format among others.

Telemetries means data having periodicity among information transmittedby the IoT device 110. Like Attributes, Telemetries can be defined byIoT service developers according to their service characteristics andcan define names, types, semantics, transmission cycle, and others.

It is recommended to define Attributes for data that is not valued forhistory but the latest information. For example, since the locationinformation of the IoT device 110 is recommended to be set as Attributesfor use because only the latest location of the device is significantinformation. Certainly, when one needs a history of the position changeof the IoT device 110, the location information transmitted by the IoTdevice 110 may be set as Telemetries. For example, in case of trackingservice, the significance is in location information which then needs tobe transmitted periodically, wherein the location information ispreferably defined as Telemetries rather than Attributes.

Data with periodicity or historical records that are deemed significantare better defined as Telemetries. For example, when the temperatureinformation measured by a temperature sensor of the IoT device 110 isperiodically transmitted to the IoT platform server 130, thisinformation becomes Telemetries information. On the contrary, when someIoT services to be provided need no history of the temperature change ofthe IoT device 110, the temperature information transmitted by the IoTdevice 110 may be set as Attributes.

(2) Example Device Descriptor

The IoT service developer may write a device descriptor 631 describingdetailed information about the IoT device 110 according to a ruledefined by an IoT platform according to at least one embodiment of thepresent disclosure.

The following is an example of the device descriptor 631.

{“name”: “Air Conditioner”, “title”: “air conditioner descriptor”,“description”: “This device descriptor 631 is a descriptor that containsa specification for an air conditioner.”, “info”: { “memory”: 1024,“model” : “AU1024ZU17”, “manufacturer” : “SKTelecom” , “type”: “AirConditioner” } , “data”: { “format”: “csv”, “delimiter”: “|”,“attributes”: [ { “name”: “switch”, “semantic”: “power”, “writable”:true, “writableValues”: [“on”, “off”], }, {“name”: “temp”, “semantic”:“temperature”, “writable”: true, “writableValues”: [15, 16, 17, 18, 19,20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30], “type”: “number” } ],“telemetries”: [{ “name”: “ts”, “semantic”: “timestamp”, “interval”: 60,“type”: “posix”}, { “name”: “temp”, “semantic”: “temperature”,“interval”: 60, “type”: “number” }, { “name” : “h” ,“semantic”:“humidity”, “interval”: 60, “type”: “number” } ] }}

(3) Setting Device Descriptor

The IoT service developer may select the device descriptor 631 whileregistering the IoT device 110 which is a target of the developed IoTservice. In particular, when a certain IoT device 110 is registered withthe IoT platform server 130, the IoT service developer may set what kindof device descriptor 631 the IoT device 110 belongs to.

The device descriptor 631 contains all the definitions of the device,such as what kind of device it is, which sensors and actuators it has,what rules are associated with the actions that can be performed, andwhat are the semantics, formats, and transmission cycles of thetransmitted data. Devices of the same kind will refer to a commonspecification.

(4) Data Validation with Device Descriptor

Since the device descriptor 631 includes a definition of a data format,the present disclosure is also capable of providing a function ofdetermination and immediate processing of an actual data value. Whenreal-life IoT devices 110 are registered with the IoT platform server130 according to at least one embodiment of the present disclosure, theyare supposed to be defined as being relevant to what specific devicedescriptors 631, whereby enabling the IoT platform according to at leastone embodiment of the present disclosure to interpret the information ofthe actual IoT devices 110 and their transmitted data, and accordinglyprovide a variety of functions in the platform stage.

As an example, the IoT platform server 130 according to at least oneembodiment of the present disclosure further includes the check unit 670which may check the validity of data received from the IoT device 110.

The check unit 670 may determine that the data received from the IoTdevice 110 have an error or some missing data when their transmissiondoes not occur once every transmission cycle as defined in the devicedescriptor 631.

In addition, the check unit 670 may determine that the data receivedfrom the IoT device 110 have an error when they have a value outside thenumerical range as defined in the device descriptor 631.

Further, the check unit 670 may determine that the data received fromthe IoT device 110 have an error when they are transmitted in a formatdifferent from that as defined in the device descriptor 631.

In addition, the check unit 670 may determine that the data receivedfrom the IoT device 110 have an error when they change beyond thevariable range as defined in the device descriptor 631.

FIG. 7 is a block diagram showing in detail the structure of an IoTsystem according to another aspect of the present disclosure.

As shown in FIG. 7, an IoT system 700 according to another aspect of thepresent disclosure includes one or more IoT devices 710, an IoT platformserver 730, and an application server 750.

The IoT device 710 means Thing in the Internet of Things (IoT), and inone embodiment of the present disclosure, the IoT device 710 refers to anode having a sensor, an actuator, and the like and to a gateway towhich a plurality of nodes are connected.

The IoT platform server 730 is a server on which the IoT platform isimplemented, and provides various functions for developing and operatingan IoT service.

The device descriptor 631 refers to a specification of common featuresof the common feature IoT devices 710 as described above. The devicedescriptor 631 is a logical framework representing the common featuredevices. The device descriptor 631 holds not merely a devicespecification, but all information such as a specification, connectedsensors and actuators, and the semantics of the transmitted data, itsformat, and the transmission cycle. The device descriptor 631 is thelogical representative factor of the connected devices.

Where the device descriptor 631 represents the common feature devices,the shadow devices are mapped 1:1 with the physical devices so that eachdevice is logically present on the IoT platform server 730. The shadowdevices may be mapped not only to the physical devices but also tovirtual devices.

The IoT service user refers to a person who actually uses the IoTservice, and may own the IoT device 710 or use the IoT service.

The IoT service developer represents a person who develops an IoTservice by using the IoT platform, and may or may not be the same as theIoT service user.

The basic function of the IoT platform is to receive the data of the IoTdevice 710 in good condition and pass it to the application server 750.The IoT platform is adapted to first provide the function fortransmitting a control command issued from an application program or“app” of the application server 750 to the IoT device 710 and furtherprovide various featured functions such as an API function, a UI editingfunction, etc. required for making various IoT services.

The conventional IoT platform is focused on managing the connection ofthe IoT device 710 and delivering data to the application server 750without losing data. Although suited to providing basic functions forreliable delivery of data, the prior art is yet to present aspecification of data toward analyzing IoT data and providing additionalmeaningful information. Because of the shortcoming, to perform taskssuch as data delivery, consistency check, and data analysis requiresadditional works in those regards at an app level.

In contrast, using the IoT platform according to at least one embodimentof the present disclosure, the IoT service developer can easily processand manage information necessary for the IoT service with the devicedescriptor 631. Since the device descriptor 631 has not only thespecification of the IoT device 710 but also the type and format of datato be transmitted, and even the semantics, the IoT service developer cannow offer various services by using such a device descriptor.

The device descriptor 631 acts as basic information which providescollecting data and taking actions in context with data semantics, inaddition to simply passing data and giving control commands. Thisenables the IoT service developer utilizing the device descriptor 631 toeasily access various services required for the IoT service, and allowsthe developer to not only easily update the properties and functions ofvarious devices, but also simplify the management and service accesstherefor.

The IoT service developer may connect several services to a singledevice descriptor 631. For example, one device descriptor 631 may bedefined and the desired rule may be set for a specific sensor valuetherein, or the entire data may be processed through a rule engine andsent to a data analysis tool. Data may also be sent out only for acertain period through a configuration based on the device descriptor631.

For example, assuming that an IoT service developer is creating an IoTservice related to a gas advanced metering infrastructure (AMI), andinstalls one hundred gas meters with common features, the developer mayfirst write the device descriptor 631 for describing the gas meter.Then, when registering the actual meters to the IoT platform, thedeveloper is advised to specify which device descriptor 631 the metersbelong to.

When it is desired to send a rule that needs to be commonly applied tothe meter reading data or specific data to an analysis system, the IoTservice developer can perform the desired configuration based on thedevice descriptor 631 without specifying the individual meters. Forexample, when information is transmitted from a meter belonging to aspecific device descriptor 631, the data may be analyzed and processedbased on sensor information defined in that device descriptor 631.

Hereinafter, an example of using the device descriptor 631 will bedescribed.

Use of Device Descriptor

(1) Linking to Various Rule Engines

With the device descriptor 631, a developer can know the semantics ofdata transmitted from the IoT device 710, and thereby link the dataeasily to various rules. For example, when an air conditioner is desiredto operate automatically when the discomfort index rises more than, say,70, the developer may calculate the discomfort index by compounding theinformation submitted by the humidity sensor with the informationsubmitted by the temperature sensor and set up a rule for giving controlcommands. With the device descriptor 631 including information onsemantics, data submitted in any form may be easily linked to the ruleengine to set a rule. The detailed manner of this operation will bedescribed below.

{circle around (1)} The IoT service developer describes and registersdevice descriptors 631.

{circle around (2)} When registering IoT devices 710, the developerdefines which device descriptors 631 the IoT devices 710 belong to.

{circle around (3)} When the actual IoT devices 710 transmit data, thedeveloper has the IoT platform interpret the data through the devicedescriptors 631.

{circle around (4)} When desiring to have an action according to aspecific sensor value, the IoT service developer or user defines acorresponding rule. In the above example, the developer compounds thetemperature and humidity data to calculate the discomfort index anddefines a rule that performs responsive actions.

{circle around (5)} When defining a rule, the developer determines a setof sensors to be combined to calculate the discomfort index bydesignating the sensors defined in the device descriptor 631.

{circle around (6)} When the data is transmitted, the IoT platforminterprets the data based on the device descriptors 631, calculates thediscomfort index according to the rule, and then proceeds to process bythe rule.

(2) Linking to External IoT Data Analysis Service

Most data analysis services are available only with a defined schema. Inan IoT service arrangement, it is common that no schema is defined indata because the data needs to be reduced as much as possible due toissues like sensor device power, price, and communication fee. However,with the device descriptor 631, the present disclosure has the informedsemantics of the data sent from devices to allow easy interworking withan external analysis service.

(3) Malfunction Check

Occasional omissions of sensor data periodically transmitted from theIoT service may pose a significant problem depending on the serviceproperties. Since the device descriptor 631 of the IoT platformaccording to at least one embodiment of the present disclosure includesa data transmission cycle of the sensor, the sensor data can be checkedat the platform stage, and thus, data omissions or malfunction can beeasily confirmed.

(4) Data Consistency Check

With the device descriptor 631 holding information on both the semanticsand the format of the data, one can check data consistency at theplatform stage. For example, where the semantics are defined in degreesCelsius when data transmitted from the IoT device 710 is ‘−300’ which isan impossible value, it is immediately known that the data is in error,to which a platform-level response becomes available. Similarly, whendata is transmitted in a format other than a pre-agreed format, it isimmediately known that the data is in error, to which a platform-levelresponse becomes available.

(5) Linking to Service Available for Device Set

Devices with the same device descriptor 631 can be linked to the sameservice, which empowers IoT service developers using the platform tomore easily develop IoT services.

FIG. 8 is a flowchart illustrating a method of providing an IoT platformservice according to yet another aspect of the present disclosure.

As shown in FIG. 8, the method of providing an IoT platform serviceaccording to yet another aspect of the present embodiment may includesteps of registering a specification (‘device descriptor 631’) forcommon features of a plurality of devices (S810), receiving a connectionrequest from one or more IoT devices 710 (S820), generating a shadowdevice corresponding to each IoT device 710 (S830), receiving data fromthe IoT device 710 (S840), and updating the state of the shadow devicebased on data received from the IoT device 710 (S850).

According to at least one embodiment of the present disclosure, themethod for providing an IoT platform service further includes a stepS840 of determining validity of the data received from the IoT device710 based on the device descriptor 631 between the receiving of datafrom the IoT device 710 and the updating of the state of the shadowdevice.

The process of determining validity will be described in detail. Datacan be determined as having an error when the data with theirtransmission cycle defined in the device descriptor 631 are nottransmitted at every transmission cycle, when the data with theirnumerical range defined in the device descriptor 631 have a valueoutside the defined numerical range, when the data with their formatdefined in the device descriptor 631 are transmitted in a formatdifferent from the defined format, or when the data with their variablerange defined in the device descriptor 631 fluctuate beyond the definedvariable range.

To avoid redundancy, details that overlap with the above descriptionwill be omitted.

As described above, FIG. 4, FIG. 5, and FIG. 8 are illustrated withtheir processes being performed sequentially, although the presentdisclosure is not necessarily limited thereto. In other words, FIG. 4,FIG. 5, and FIG. 8 are not limited to the illustrated chronologicalsequences because they may be modified in practice of the presentdisclosure, or have one or more of those processes of FIGS. 4, 5, and 8performed in parallel.

The method of providing an IoT platform service according to someembodiments illustrated in FIGS. 4, 5, and 8 may be implemented as anapp. (or a program) and recorded on a recording medium readable by aterminal device (or a computer). A non-transitory computer-readable (orterminal-readable) recording medium may be provided for recording anapp. (or program) for implementing the IoT platform service providingmethod according to some embodiments and include any type of recordingdevice on which data that can be read by a computer system arerecordable.

Although exemplary embodiments of the present disclosure have beendescribed for illustrative purposes, those skilled in the art willappreciate that various modifications, additions, and substitutions arepossible, without departing from the idea and scope of the claimedinvention. Therefore, exemplary embodiments of the present disclosurehave been described for the sake of brevity and clarity. The scope ofthe technical idea of the present embodiments is not limited by theillustrations. Accordingly, one of ordinary skill would understand thescope of the claimed invention is not to be limited by the aboveexplicitly described embodiments but by the claims and equivalentsthereof.

The invention claimed is:
 1. A method of providing an Internet of Things(IoT) platform service, the method comprising: registering at least onedevice descriptor for common features of a plurality of devices, whereinthe device descriptor comprises a transmission cycle of common datatransmitted by the plurality of device, information on sensors common tothe plurality of devices, information on controllable modules common tothe plurality of devices, and information on semantics, format andperiodicity of the common data transmitted by the plurality of devices;receiving a connection request from at least one IoT device; generatingat least one shadow device corresponding to the at least one IoT device;receiving the common data from the at least one IoT device; determiningthat an error has occurred when the common data is not receivedaccording to the transmission cycle defined in the device descriptor;and updating a state of the at least one shadow device based on thecommon data received from the at least one IoT device.
 2. The method ofclaim 1, further comprising: determining a validity of the common datareceived from the at least one IoT device based on the at least onedevice descriptor between the receiving of the common data and theupdating of the state of the at least one shadow device.
 3. The methodof claim 2, wherein the determining of the validity comprises:determining that the received common data have an error when the dataindicates a value outside a numerical range defined in the at least onedevice descriptor.
 4. The method of claim 2, wherein the determining ofthe validity comprises: determining that the received common data havean error when the received common data is in a format different from adefined format defined in the at least one device descriptor.
 5. Themethod of claim 2, wherein the determining of the validity comprises:determining that the received common data have an error when values ofthe common data fluctuate beyond a variable range defined in the atleast one device descriptor.
 6. The method of claim 1, furthercomprising: registering the at least one IoT device; and setting adevice descriptor of the at least one IoT device as one of the at leastone device descriptor.
 7. The method of claim 1, further comprising:linking the at least one device descriptor to a predefined rule or arule engine which defines the predefined rule.
 8. The method of claim 7,wherein the predefined rule is configured to be related to one or moresensors defined in the at least one device descriptor.
 9. The method ofclaim 7, further comprising: interpreting the common data received fromthe at least one IoT device based on a corresponding device descriptor,which is one of the at least one device descriptor and processing thecommon data by the predefined rule.
 10. An Internet of Things (IoT)platform server, comprising: a processor; and memory storinginstructions thereon, the instructions when executed by the processorcause the processor to: register at least one device descriptor forcommon features of a plurality of devices, wherein the at least onedevice descriptor comprises a transmission cycle of common datatransmitted by the plurality of device, information on sensors common tothe plurality of devices, information on controllable modules common tothe plurality of devices, and information on semantics, format andperiodicity of the common data transmitted by the plurality of devices;communicate with at least one IoT device to receive the common data fromthe at least one IoT device; generate at least one shadow devicecorresponding to the at least one IoT device; determine that an errorhas occurred when the common data is not received according to thetransmission cycle defined in the device descriptor; and update a stateof the at least one shadow device based on the common data received fromthe at least one IoT device.
 11. The IoT platform server of claim 10,wherein the instructions further cause the processor to determine avalidity of the common data received from the at least one IoT devicebased on the at least one device descriptor.
 12. The IoT platform serverof claim 11, wherein the processor determines that the received commondata have an error when the common data indicate a value outside anumerical range defined in the at least one device descriptor.
 13. TheIoT platform server of claim 11, wherein the processor determines thatthe received common data have an error when the received data are in aformat different from a defined format defined in the at least onedevice descriptor.
 14. The IoT platform server of claim 11, wherein theprocessor determines that the received common data have an error whenvalues of the common data fluctuate beyond a variable range defined inthe at least one device descriptor.
 15. The IoT platform server of claim10, wherein the processor interprets the common data received from theat least one IoT device based on a corresponding device descriptor,which is one of the at least one device descriptor and processes thecommon data by a predefined rule.
 16. A non-transitory computer readablestorage medium in an Internet of Things (IoT) platform server, themedium storing instructions thereon, the instructions when executed by aprocessor cause the processor to perform operations of: registering atleast one device descriptor for common features of a plurality ofdevices, wherein the at least one device descriptor comprises atransmission cycle of common data transmitted by the plurality ofdevice, information on sensors common to the plurality of devices,information on controllable modules common to the plurality of devices,and information on semantics, format and periodicity of the common datatransmitted by the plurality of devices; receiving a connection requestfrom at least one IoT device; generating at least one shadow devicecorresponding to the at least one IoT device; receiving data from the atleast one IoT device; determining that an error has occurred when thecommon data is not received according to the transmission cycle definedin the device descriptor; and updating a state of the at least oneshadow device based on the common data received from the at least oneIoT device.